@jonathan-mayer rebased and included the previous suggestions. Just a couple of things to note:

1. Pre-Commit failed because the specific getResourceFunc for each resource has duplicate code" detected (which is true because the logic is shared across them). So, eventually, we should try to think about a strategy to tackle that
2. Pre-Commit also suggested to lower a bit startScanning complexity. What would you refactor inside that?

Ill have a look over it.

1. Pre-Commit failed because the specific getResourceFunc for each resource has duplicate code" detected (which is true because the logic is shared across them). So, eventually, we should try to think about a strategy to tackle that

I do get that it detects it as duplicate, but im not entirely sure how to avoid it. I think in theory it is avoidable by just having list and get in separate functions. Another way would also be to refactor to use the dynamic client again, although i would still like to avoid that.

2. Pre-Commit also suggested to lower a bit startScanning complexity. What would you refactor inside that?

I think we could refactor the function called in the go routine out.

1. I perfectly agree with you, I don't see anything wrong with having them duplicate. I would nolint them
2. I'll extract the go routine from the function

@jonathan-mayer I refactored the go func out of the startScanning function however I'm not sure what could be the best name for the that. attemptScan was the best I came up with

@jonathan-mayer I refactored the go func out of the startScanning function however I'm not sure what could be the best name for the that. attemptScan was the best I came up with

i think the current function name should be good for now. Although i would not put a anonymous function in the attemptScan function, but instead just run the attemptScan function in a goroutine so go attemptScan(). Also just a heads up, it might take some time until i get around to reviewing this.

Don't worry Jonathan, absolutely no rush take your time

I think we should change up the GetResource funcs again. They should only handle listing and then every scalableResouce should have a re-get function which regets itself from kubernetes. it could like something like this:

func (c *cronJob) Reget(clientsets *Clientsets, ctx context.Context) {
	*c, err = clientsets.Kubernetes.BatchV1().CronJobs(c.Namespace).Get(c.Name, ctx,, metav1.GetOptions{})
	if err != nil {
		// TODO handle error
	}
}

I think we should change up the GetResource funcs again. They should only handle listing and then every scalableResouce should have a re-get function which regets itself from kubernetes. it could like something like this:

func (c *cronJob) Reget(clientsets *Clientsets, ctx context.Context) {
	*c, err = clientsets.Kubernetes.BatchV1().CronJobs(c.Namespace).Get(c.Name, ctx,, metav1.GetOptions{})
	if err != nil {
		// TODO handle error
	}
}

Implemented, the linter still complains about 2 things:

• deployment/statefulset class duplication
• RegetWorkload and its specific methods returns an interface type

I mean the first one could be true, for the second one to me it seems legit to return an interface type in that case

refactored the way you suggested, still having "duplicate" suggestion on linting. I think we can't do much about that

Oh actually add the nolints for the dupl linter suggestion, then we can merge

Done